[WP] Add is_session_leader field to process events#48307
[WP] Add is_session_leader field to process events#48307loresuso wants to merge 2 commits intoDataDog:mainfrom
Conversation
5705414 to
d93f625
Compare
|
All contributors have signed the CLA ✍️ ✅ |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5705414150
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
d93f625 to
71464db
Compare
6c88473 to
d56a9f8
Compare
|
I have read the CLA Document and I hereby sign the CLA |
|
recheck |
43addd7 to
b704d29
Compare
b704d29 to
0bef8b2
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
PR already in the queue with status waiting |
Add a new boolean field `is_session_leader` to CWS process events that indicates whether a process is a session leader (PID == SID). The session ID is read from the kernel via: task->signal->pids[PIDTYPE_SID]->numbers[0].nr and compared against the process tgid. Two new kernel offset constants are introduced (task_struct_signal_offset, signal_struct_pids_offset) resolved via BTF at runtime. The field is exposed in SECL as process.is_session_leader and propagates to all process-related event types (exec, exit, signal, ptrace, etc.). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0bef8b2 to
56ea633
Compare
- Use bitfield for is_kworker and is_session_leader in process_context_t, keeping the struct at 40 bytes instead of growing to 48 - Restore the original if/else in exec handler cookie update Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
56ea633 to
68c957f
Compare
|
closing in favor of a non-fork PR |
| if (sid_pid) { | ||
| u32 sid = 0; | ||
| bpf_probe_read_kernel(&sid, sizeof(sid), (void *)sid_pid + get_pid_numbers_offset()); | ||
| fork_entry->is_session_leader = (sid != 0 && sid == tgid) ? 1 : 0; |
There was a problem hiding this comment.
I'm wondering if it's not better to send the sid to the user space and then add the boolean field. We might use the sid at some point no?
Add a new boolean field
is_session_leaderto CWS process events that indicates whether a process is a session leader (PID == SID).The session ID is read from the kernel via:
and compared against the process tgid. Two new kernel offset constants are introduced (task_struct_signal_offset, signal_struct_pids_offset) resolved via BTF at runtime.
The field is exposed in SECL as process.is_session_leader and propagates to all process-related event types (exec, exit, signal, ptrace, etc.).
Example of condition where this could be useful: spawning of a session leader shell from a not known binary (e.g. a shell given by the
shellcommand of a sliver C2 implant